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ABSTRACT 

The NASA Integrated Vehicle Health Management (IVHM) Technology Experiment for X-37 was intended to run 
i™Vsoftl on-board the X-37 spacecraft. The X-37 is intended to be an unpiloted vehicle that would orbit the Earth 
for up to 21 davs before landing on a runway. The objectives of the experiment were to demonstrate the benefits ofm- 
flmhMVHM to the operation of a Reusable Launch Vehicle, to advance the Technology Readiness Level of this 
technology within a flight environment, and to demonstrate that the IVHM software could operate on the Vehicle 
Management Computer' 'The scope of the experiment was to perform real-time fault detection and isolation for Xo7 
d«mfoaTpovrerTvstmn and electro-mechanical actuators. The experiment used Livingstone a software system ha 
performs dumosis usina a qualitative, model-based reasoning approach that searches system-wide interactions to detect 
and Sate SS Two offoe challenges we faced were to make this research software more efficient so that it would 
fit within the limited computational resources that were available to us on the X-3 / spacecraft, and to modify it so 

satisfied the X-37's software safety requirements. 

Although the experiment is currently unfunded, the development effort had value in that it resulted m major 
topr„« “ LiimgsM* efficiency and saf«y. This paper re.rcws son,, of ,he derails of the modeling and 

integration efforts, and some of the lessons that w'ere learned. 
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1. INTRODUCTION 


Perhaps the most substantial single obstacle to the progress of space exploration is the cost of launching to and returning 
S ac The primary influence in the high col of current systems is the operations, maintenance and ^sHucmre 
po2f of the program’s total life cycle costs. Incorporation of Integrated Vehicle Health Management (E^) 
technologies into 2°* and 3 rd Generation Reusable Launch Vehicles (RLVs) will result in significant program life cycle 
savings by improving reliability and lowering operational costs: 

Life cycle costs for the next generation RLVs include safety and mission assurance. They will be dominated by the cost 
ofprocess in? operating and maintaining the vehicle and the time required for turning the 

missions buT safety is still a critical component. Advanced IVHM technologies are critical to the cost-effective 
management of the vehicle and for the determination of the maintenance actions required prior to the next mission. 


This experiment was one of a number of flight and ground 
demonstrations planned by NASA to develop and mature critical IVHN 
technologies and to demonstrate the relevance and importance of IVHM 
technology to the future of the space transportation program. The 
eventuaf adoption of this technology will require a number of 
compelling experiments that demonstrate the ability of the technology to 
handle a broad class of failures and to perform robustly within an 
operational scenario. Furthermore, to gain acceptance the IVHM 
software must also demonstrate that it “plays well” in the avionics 
hardware and software environment of an operational vehicle without 
imposing a lot of additional requirements on the avionics hardware 
configuration. 

1.1. Background 

On xxxx date, NASA, the USAF, and The Boeing Company entered into 
a cooperative agreement to develop a new experimental space plane 



Figure 1 - The X-37 spacecraft 
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called the X-37. The X-37 is intended to be the first of NASA’s fleet of reusable launch vehicle experimental 
demonstrators to test future launch technologies in both the orbital and reentry phases of flight. The X-37 is planned to 
be an unpiioted vehicle that wouia be launched from the Space Shuttle’s cargo bay, or from an expendable launch 
vehicle, and then orbit the Earth for up to 21 days before landing autonomously on a runway. The X-37 is shown in 
Figure 1. 

There were originally a total of 32 technology demonstrations and 8 experiments on the X-37, including a NASA IVHM 
experiment. The IVHM experiment was intended to demonstrate IVHM technology developed at NASA Ames Research 
Center. The IVHM experiment was led by NASA .Ames Research Center working in conjunction with Boeing. A Task 
Agreement between NASA .Ames Research Center and Boeing was signed on March 6, 2000. 

The X-37 IVHM experiment incorporated the Livingstone model-based health management systemfl]. The Livingstone 
system was initially demonstrated as part of the Remote Agent Experiment on Deep Space One (DS1)[2]. Livingstone is 
a model-based inference engine that reasons about system- wide interactions to detect and isolate failures. It uses a high- 
level qualitative model of the components in which both nominal and off-nominal modes are modeled. The Livingstone 
system uses this model to track commands as they are sent to components and detects discrepancies between the 
available observations and the predictions of the model. When an anomaly is detected, Livingstone uses advanced 
techniques to efficiently search the space of both single and multiple -point possible failures to select the most likely 
failure that is consistent with the available observations. Once the failure is identified, Livingstone continues to monitor 
the system using its knowledge of the nominal and off-nominal behavior of the failed components. 

Livingstone provides a number of potential advantages to 2 nd and 3 rd generation RLVs. Livingstone uses a high level, 
qualitative model identifying components and their interaction to perform system-level health management. By using a 
model of the actual system, Livingstone is able to reason about complex system interactions within a real-time 
monitoring and control loop, rather than requiring an engineer to reason through all possible interactions and then 
program in the appropriate response to a pre-deflned set of failures. Also, as changes are made to the hardware design, 
updating and verifying the model is straightforward and less labor intensive than the task of identifying changes required 
in explicit procedural code. The model-based level of representation streamlines the software development process and 
maximizes code reusability across vehicles. Finally, the use of a model facilitates the generation of an explanation or 
justification of the diagnosis allowing the human operator to decide whether the diagnosis is reasonable before selecting 
or confirming the appropriate recovery action. c 

Note that Livingstone is only one of many technologies that are relevant to the broader task addressed bv an IVHM 
system. This experiment was only designed to provide a limited demonstration of select IVHM capabilities. Specifically, 
this experiment iocused on the real-time processing of component health information to provide fault detection, 
isolation, and recovery while in operation and during vehicle checkout. It was not designed to detect subtle degradations 
in component performance that requires a maintenance response prior to the next mission (prognosis). The experiment 
would only identify required maintenance actions when the characteristic of the failure could be defined a-priori and are 
observable within the available sensor data. The experiment was, however, a first critical step towards a more complete 
real-time and life-cycle-based IVHM system for enabling safe, cost-effective re-usable launch vehicle fleets. 

On xxx, due to lack of funding, effort on this experiment was stopped before the first round of integration with the 
vehicle. Several development cycles were never implemented. The original experiment scope will be described below, 
but this document is primarily intended to describe the final state of the integrated flight software for the experiment 
when it was cancelled, i.e. when it was ready for initial integration efforts with Boeing. 

1*2* Objectives 

The goal of the X-37 IVHM flight experiment was to advance the technology readiness level of the Livingstone 
reasoning system within a flight environment and to begin its transition from experiment status to inclusion in future 
operational vehicles. 

The main objectives of the X-37 IVHM experiment were to 1) provide a limited demonstration of the benefits of in- 
flight IVHM to the operation of an RLV, 2) advance the TRL of Livingstone 2 (L2) within a flight environment, and 3) 
demonstrate that the IVHM software could operate with the Vehicle Management Software (VMS) on the Vehicle 
Management Computer (VMC). To meet these objectives the flight software experiment would monitor sensor data from 
the above subsystems, perform real-time fault detection and isolation, and identify potential recovery actions of the X-37 
vehicle throughout selected mission phases, while running on the X-37 VMC. This experiment focused on the real-time 



processing of component health information .0 provide autonomous on-board fault detection, isoiation and recovery 
functions during flight operations and during vehicle processing and ground checkout. 

A kev aspect of this experiment is that the IVHM software would be running in the same “ ^Tonf' septate 
VMS This experiment differed from other X- vehicle IVHM programs that have run the IVHM code on a separate 

comDUter and represented an important step towards more efficient on-board computer utilization, y emons a mg e 

and VMS software combined in a single software module, running on a single 
compute^confidence 3 would be gained for this type of operation on future reusable launch vehicles^ Many of our 
challenges were tied to constraints resulting from our goal to implement IVHM on the existing flight compute . 

Some of the specific functional requirements for the IVHM software experiment included: 

1 The flight experiment shall be capable of identifying certain non-nominal states from sensor readings. 

2 ! £& “pSmcn. shall be capable of idemrfyiug sensor failures when possible from redundant sensors or 

3 ° M When^enMUailu^ 0 a« U nJlell oul. the flight experiment shall be capable of declaring subsystem performance 
anomalies from non-nominal data. The goal shall be to isolate the failed component ^ down l ink t0 the 

4. Diagnostic and reconfiguration/recovery recommendations shall be provi 

f^The data downlinked shall be sufficient to determine the status and performance of X-37 subsystems/components 
and for determination of experiment status and verification of experiment performance. 

rt IVHM software was originally planned to assess the health of the X-37’s control surface and nose wheel steering 

and assoc, ared elecrical power system (EPS) -“^con” c ,“S 
with an emphasis on pre de-orbit checkouts, re-enmy. and pre- and post- launch. The EMAs control 
aerodynamic surfaces during re-entry and landing, and nose wheel steering during landm & 

There' were two orbttal flights (one of 2 days, another of 21 
the Livingstone model before the orbital flights. 

The X 37 had a Vehicle Management Computer (VMC), which ran the Vehicle Management System (VMS) software as 

bid sever, Jo, ions. 

^^aluewnd"^ coL^X fromTe "Xs" task, and provided its outputs (diagnoses) to the VMS task to be 

downlinked to the ground. , , 

To ensure vehicle safety, the expenm^U and" pmcSsing 

due to technology readiness levels, and aggressive cost ana scncuuic 0 ^a r , Y wnnlH not 

There were five major task areas that NASA performed to get Livingstone ready to fly on X 37. 

Port the Livingstone inference engine from LISP to C++ and meet Boeing safety requirements. 

Develop the interface between Livingstone and the X-37 vehicle management software 
Develop monitors to be used by the Livingstone model 

S:. p e^sr" «*«. - >«*"* •“* » f the resui,i " 8 

system. 

VMS for downlink. The experiment status is likewise provided for downli . 
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igure - shows the architecture of the IVHM experiment. The Vehicle Management Software (VMS), written by 
Boeing, and the rVHM software would run on the same Vehicle Management Computer (VMC). Among its other 
functions, tne VMS commands the power system, acquires subsystem status and sensor information, 0 monitors 
commands issued by the Flight Management Computer (FMC), and stores this vehicle state information in a shared 
memory area. The IVHM software would retrieve the vehicle state data and commands from shared memory. Monitors 
translate the real-valued sensor data into a discrete representation to be used by Livingstone. These discrete values 
would then be fed into the vehicle model. The vehicle command stream would also be made available to the IVHM 
software in order to identify divergent behavior. The model would generate diagnoses. The IVHM software would never 
irect v command any vehicle subsystems and under no circumstances would its recommendations be acted upon 
automatically by the vehicle. Rather, the IVHM outputs would be placed in the IVHM area of shared memory for 
insertion into the telemetry stream and relay to the ground station. The VMS would then telemeter this information to the 
ground, where ground software would process and display the information 



Ground Station 


Figure 2 — X-37 Livingstone Overview 

1*5. Challenges 

Running Livingstone on the VMC presented some special challenges. First, the resources available to the experiment 
(CPU, memory, and telemetry bandwidth) were very limited. Second, the VxWorks 5.4 operating system does not 
provide any memory protection, so a bug in our software that caused it to write into the VMS task’s memory space could 
have crashed the VMS and thereby resulted in the loss of the vehicle. Because of this risk, Boeing required our code to 

meet certain safety standards (such as no dynamic memory allocation and no pointer arithmetic), and to undergo verv 
thorough testing. 

2. SOFTWARE COMPONENTS 

2.1. Livingstone 

Livingstone is a software package that uses a search process to diagnose problems in a complex system that has been 
described using a declarative modelfl], Livingstone was developed at NASA’s Ames Research Center. A previous 
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version of Livingstone which was written in LISP, was successfully flown on board the Deep Space 1 spacecraft^]. The 
Z UTS Ltogslone (L2) is written in CriK In order to fly Livingstone on X-37, the Mowing m od,ficnt,ons 

to Livingstone were completed by the X-37 IVHM team: 

Livinsstone w r as ported to VxWorks r , , 

Livingstone was modified for flight code to satisfy the following Xo7 safety standards. 

• No dynamic memory allocation 

• No recursion 

Livinastone was interfaced with the VMS , j f 

We implemented routines to allow Livingstone to use a binary representation of the model, to avoid the need 

fly the XML parser used in the current implementation 

2.2. Monitors , „ , . • . 

Because Livingstone is onlv able to take discretized values as inputs, it is necessary to translate all sensor values t 
discretized values This is the task of the monitors. There are command and sensor monitors. Command monitors are C 
Wtions thaMake as input the commands provided by the VMS (eg. 0 or 1), and translate these commands into the 
format needed by Livingstone (such as on or off;. Sensor monitors are C functions that 
values into discrete values. There are four types of sensor monitors, corresponding to different typ 
37 subsystems covered: 

. ^ TranslateOneBit monitors interpret on-off sensor values. The monitors echo the on-off value. 

. TranslateSSPCStatus monitors interpret sensors with three status bits. The monitors will return the bit pattern 
passed from these sensors. 

• Bin/threshold monitors interpret floating-point sensors that need to be placed in a bm where ' a 

corresponds to a bin. For example, a temperature value can be ‘‘low , nominal , or high according 
whether its value lies in the different ranges corresponding to these bins. 

. Compare monitors interpret floatina-point position sensors for the aerodynamic control surfaces. The desired 
values that the monitor should return are MOVING and NOT.MOVING. Thus the compare the 
difference between successive sensor values to determine whether its output should MOVING 

NOT._MOVL\'G 

implemented in the monitors. , 

wmmmrnmm 

level then the monitor will report the new value. 

confidence is determined independently from persistence. There are a states of confidence. 

. Full confidence - equivalent to reporting the current bin consecutively « times, where n is the persistence leve . 

. Partial confidence - monitor reports previous value, but if next output from the monitors is not the current 
output, the monitors will report UNKNOWN. 

• No confidence - the monitor reports UNKNOWN 


Thus h^re are ^ counted Tw , ' * ^ 3 30 COnfldence state » a partial confidence state 

“ ™ 2 f dlSCrCte VajUC> ° nC fOT consecudve “not current values” for switching to partial 

confluence, and another for restoration of partial and full confidences. = t0 partiaI 

Wrfe” a^de scribed abo ve ^ ' ^ tnmSiti0 " ^ ^ by P3r3meterS - Persistence and confidence filters are also 

When tuning the noise filtering in the monitors, there is a tradeoff between false positives and false negatives Tf th„ • 

' “" ere * % «* *? 12 «■ *1 l s „:u„t:rr;s ztzz 

noise. " n ° 1Se g ' there IS thC risk th3t 3 reai failure wil1 be hissed because it is assumed to be 

2.3. Models 

^' ng ! t0 f ne ° lakeS USC of a declarative model of the system being diagnosed. ARC completed an initial model of the X 
■f s electrical power system and electro-mechanical actuators. This model was compiled into a biXfilHJ ch was m 
be provided to Boeing for inclusion in the VMC’s Hash RAM. F y ’ “ Ch t0 

The initial scope of the model was intended for the drop tests with an understanding that there would be time m 

LiV ‘" gS,0ne m ° dd bef " e ^ ° rbiB1 ^ ™ s Livingsrone 

The Livingstone mode! for the X-37 consists of a single thread (no redundancy) from the hi<>h-voIta ? e batteries to the 
electro-mechanical actuators (EMAs). Six of the nine actuators are modeled (the nosewheel steerinAnd fcust ’vector 

modd sTr ", TJ ^ R l d ^ dmcy " d dl ' ™ for sabseqSm veSs o 7Z 

em a controller d fFMA C Ude: hlgh ' V ,° lt3 = e batter >’ high-voltage power relay, SSPCs (solid state power controllers) 

7 highlight sub-moduleswitofc toNe^m^r 3 •*** • cte "« fc ° f model Fi »“ r “ 4 

The modd consists of four mam module types: High-voltage battery, Power Control and Distribution Unit (PCDU1 

the fl ohr T and actU3tor The first two Wes comprise the electrical power system while the last two comprise 
the flmht actuanon subsystem. In addition there are 18 distinct component types within those modules The model 
consists of 9 instances of those modules, and 86 instances of._nr! ' P $ m ° dUleS ' The m ° dd 

r vuw - 



Figure 3 — X-37 Livingstone model. 















3. INTEGRATION 


3-1. Design Constraints 

In addition to the modifications made to L2 for vehicle safety requirements, there were several other constraints on the 
xpenment software. These included memory, CPU allocation, and telemetry bandwidth. These issues, along with L2 
performance, have tremendous implications in terms of 1) L2’s ability to perform real time diagnoses (if ft were to 

f ° r f eXeCUtl ° n) ’ 2) L2 ’ S ablUty t0 ^ 0Vide guidance on failures andappr^pnam 

recovery, and a) the ability of experimenters to validate L2 diagnoses in real time and post-test. P 

3.1.1. Memory Constraints 

™r f T ftW T W3 f r u equired t0 flt within a ver y amount of DRAM and Flash RAM on the X-37 vehicle 

requirements ° f ^ * USed f ° r data had t0 be reduced ^bstantially in order to fit within the 

3.1.2. CPU constraints 

The IVHM software was developed to run as a separate VxWorks task. The IVHM task was allowed a very small fixed 

rdenefde° t CydC ' ThlS constraint intr oduced the unknown element of how L2 performance 

(dependent on the model size and the actual sensor/command stream) would lag real time. 

3.1.3. Telemetry Constraints 

^ 37 W3S S “ PP ° Sed t0 have te!e metry on two bands: one low-speed, and one high-speed. The low-speed telemetry 
was to use well-known, redundant technology, which was expected to be reliable, but had a very low expected 
throughput. The high-speed band telemetry was an experiment, with no redundancy, but with a very hmh expected 
throughput. Though limited in throughput, the low-speed telemetry had expected reliability and high coverage during the 
i missions and was therefore reserved for high priority or mission critical data. Boeing constrained the rVHM° task 

bldwH^nf It? f P f SCCOnd ° n the ,0W - s P eed telemetry. We were also to get an unspecified amount of 
chi llenaf Th the hlgh ' Speed teIe ™etry with intermittent coverage. This presented the IVHM team with a significant 
challenge. The interface between Livingstone and the VMS had to balance the desire to get information to the ground 
(operational and experiment status) with the limited RAM available for output queues. 

3.2. Communication 

^s°^r nS r eiVinS SenSOr inpUt ’ reCeiVmg thC command strea m. and telemetering output) is done via the 
frpn ‘ software communicates with the VMS using three queues that are stored in shared memory. At a fixed 

i q .?, y ’ * e ' uses the , monitors to filter the relevant sensor values and process the relevant commands, and then 

d amos^the dri SenS ° r UCS pr l CeSSCd commands the input queue. Each time Livingstone completes a 
S i™ °f ’ represented as the incremental change in the state vector, is placed in the two output queues 
Heft ^ he r . r V HNI softwnre^ removes filtered sensor values and commands from the input queue until another diagnosis is 

, A i J y ? C t , hr0Ugh ltS main loo P’ Che VMS removes as many items from the output queues as there is 

bandwidth available for downlink. NASA Ames developed a function to be called by the VMS at a fixed frequency that 
ca Is the monitors, adds the monitor outputs to the input queue, allows Livingstone to run for a fixed amount of 'time 
retrieves Livingstone s outputs from the output queues, and returns these outputs to the VMS. 

3.3. Integration Architecture 

The IVHM software uses three queues: an input queue, a low-speed output queue, and a high-speed output queue. All 
hree are first-m first-out (FIFO). The VMS places monitor outputs (filtered sensor values and commands) into the input 
queue at a fixed rate^ Thus a single input queue holds all of the monitor outputs that are input to Livingstone in 
chronological order. The IVHM task removes these items from the input queue whenever it is ready for them ’(in 
e ween diagnoses). The IVHM software places Livingstone’s outputs (diagnoses) into the output queues. The plan was 
it to place a minimal description of its diagnoses into the low-speed output queue, and a more complete description of 
its diagnoses, and how it arrived at them, into the high-speed output queue. We only implemented the nominal 

rhemTT ( 0W ' !,peed °“ tpl f qaeue) - The ™ S removes items from the two output queues at a fixed rate and downlinks 
them on the appropriate bands. The integration architecture consists of the following components, shown m Figure 2: 


Input queue writer (IQW). The VMS calls the IQW function, passing it engineering-unit sensor values and 
commands. IQ w calls the monitors, which transform the engineering-unit sensor values into “monitor 
outputs.” which are filtered sensor values that have been discretized. It also calls monitors to translate the 
commands into the format needed by Livingstone. IQW then places the monitor outputs into the input queue 
(only commands and discretized sensor values that have changed). 



Input queue reader (IQR). This function removes monitor outputs from the input queue, passes them to 
Livingstone, and calls Livingstone as necessary to perform diagnoses (see diagnosis timing policy below) 
Monitors. The functions that take as input the engineering unit sensor values and commands provi e y ..e 
VMS, and output discrete values that can be used by Livingstone. (Ml, M2, Mn in Figure xxx.. 

Livingstone. The inference engine that performs a diagnosis. _ . , . f 

Output queue writer (OQW). The function called by Livingstone to put a diagnosis and related information 

into the two output queues. , . . . 

Output queue reader (OQR). The function that the VMS would use to remove diagnoses from the two output 

queues so that they can be downlinked. 

If any of the queues becomes full, the experiment is terminated. 


2 . 

3 . 

4. 

5. 

6 . 



Figure 8: IVHM Experiment Software Architecture 


3.4. Diagnosis timing policy 

The policy engine is implemented within ihe IQW, which is within the VMS tnsk. *^££££**£2 
diagnosis should be done, and then inserts a “find candidates” into the input queue. When the IQR removes toMfl 
cSKs- tom the ihput queue, i. insists Livingston, to perform . diagnosis. The pohcy engrne incorporates 

“tunable” parameters into the interface. 

When a command is received, there is generally » small time delay before the effects of .ha, commend - *e 
sensor values If Livingstone performs a diagnosis immediately after receiving a command, then it will produce an 
incorrect failure diagnosis, since the effect of the command has not yet append ir .the 

this problem is to associate with each command a list of monitors that are affected, and the amount of time tor eacn 
effet to appear. After a command, Livingstone ignores each specified sensor for the specified period of time. We 









rh^tf 3 S ™w “I 11 '’ 0 "' r " rJHS soIutI0n - there ^ a. global time delay for all commands. After a command is issued 
t t T CI £/ m ° Unt ° f timC ’ and th6n d0eS 3 dia 8 nosis > unIess mother command is received durin* 

w'fht ’ ’ ’ " a “ S , 1 the lirst command !S issued, the system waits until there is a period of the specified length 

2w TT 5 ’ and the o d0CS a diagn ° Sk In addltl0n ’ lf £here 15 an “expected observation (one'S does ^ 
follow a command), the system does a diagnosis (after a delay, assuming that there is no command during that delay). 

In selecting the timeout after an unexpected observation, there is a tradeoff between alerting operators to the problem as 
oon as possible so that they can act on it, and waiting until enough data arrives to produce L correct dfaSosis We 
to implement a system that will obtain the correct diagnosis. It might be useful to do both: alert the operators of a 

if ^ faiIure arrives ’ and then provide 1,16 d,agnosis ° f 1 he faoure as — - 


4. TESTING 

venfied ° f S ° ftware feP “ t0 safet >'' Performance, accuracy, stability, and operational areas. We 

t . Qn , the safety requirements were met by examining the source code, either manually or usins tools that search 
Lurce lo e for prohibited items. We tested memory usage and statement coverage using CodeTEST. 

Stability testing included nominal scenario and random failure testing on the PowerPC at Ames. These tests confirm 

o? davsof n 7 mem ° ry ^ ^ “ d With ° Ut fellUreS ' We successfully simulated a nominal 21-day orbital mission in 
" d > . of continuous execution on the ARC processor without exceeding memory allowances. Stability testing was also 
onducted by providing random inputs (Monte Carlo testing) to the integrated software package. Using the Monte Carlo 
approach, we simulated ten 21-day missions in faster-than-real time. The Monte Carlo tests did not fllow us to veS^ 
accuracy since we do not know what the correct diagnosis is for a given set of random inputs. They simply allowed us 
to verify that the code does not crash or exceed its memory allocation, given a very wide range of different inputs. 

Accuracy testing was performed using a set of 28 hand-coded scenarios. No simulation data was available to test the 

“S 1, " TZT.T " d m0ni " S “ d “ Sn0SinS tmkS “ ,he and S 

electrical power system Instead, scenarios were constructed based on expected sequences of commands and 
o servations for nominal and failure operating conditions. The system produced what we believe to be the correct 

lagnosis m every case. It should be emphasized that Boeing engineers did not confirm the applicability of the scenario 
files or verify the correctness of the diagnoses. ' scenario 

This version of the IVHM software is not ready for flight as of the date of this report, because some of the softw'are 

continued woupT 06 T' “I P3SS ° r WCre n0t teSted ' The next ste P in testin S our software, had this effort 

continued, woulu have been a functional test conducted with Boeing to see if the IVHM software co-id H, ve been 
compiled and executed on their system. oee “ 


5. CONCLUSION 

5.1. Accomplishments 

X ' 37 velucle program was cancelled, a number of accomplishments were made towards the technical 
goals. Fust Livingstone software was ported from LISP to C++ under Vx Works. During this process Boein* memory 
requirements were satisfied. Specifically, DRAM usage and Flash RAM usage were both greatly reduced Most of 
Boeing s safety requuements were also met. For example, all dynamic memory allocation was removed from the code. 

.Wvr^Tr^T 1 , C ° mpleted the desi § n and development of additional flight software components required for the 
~ ™ f hW3 f e paC fl ka f (an mterface t0 Boeir 'S’ s VMS “d a testing envuonment). This included completion 
of version 1 (for atmospheric flight tests) of the X-37 subsystem models that involved single string of EMAs and partial 

project wl tea “ ?H 0n t gma ^ Planned 3n eXpanded second version of the m o d el (for orbital flight tests) before the 
project was cancelled In addition, monitor routines were developed which act as an interface between vehicle data (in 
engineering units) and L2. ' 

tfnHnreIr g + all> ARC mternaJ and 3 Boein g versions of the integrated flight code would be developed 

(formtegrationwith the vehicle, atmospheric flights, and orbital flights, respectively). Integration and testing of the first 

h T f C 6 Was f°“ pleted in November 2001. This included integrating the subsystem model, monitors, 

demonsuared S' f h J interfaCe ^ ^ ^ modified flight version of LZ Testing successfully 
demonstrated the stability of the software on a ground-based system similar to the flight hardware/software environment. 



The next phase of development would have been working with Boeing to integrate and test this version with their 
hardware/software on the ground. However, X-37 delays prevented this integration. 

No further work has been funded and the X-37 may be cancelled. An accepted approach to integration was successfully 
developed that would probably have led to safe integration with vehicle flight software. The work remaining if this code 
were to be flight-tested includes: 1) In-flight IVHM error handling and L2 initialization/restart capability, 2) Successful 
integration with flight hardware and software, and 3) Integration with ground station software. 

5.2. Limitations and Future Work 

There are a number of challenges and questions that arose during development of our software. We began to think of 
solutions for some of these items before this task was terminated. We did not have the opportunity to address these 
issues or even make serious recommendations. Many of them currently exist only as questions. 

Much of the work in creating a model is acquiring the knowledge of the systems to be modeled. What are the interfaces 
to the system? What are the observable commands and sensor readings? What is the normal operation and how do faults 
of the system manifest themselves in the observable parameters? A severe limitation of the modeling effort for X-37 was 
lack of feedback from Boeing engineers. Assumptions had to be made about the system components and operation. 
Another difficulty was the dynamic nature of the design. As the systems change, so too must the model and monitors. 

Systems must be fully characterized before applying Livingstone to diagnose them. Obviously, model-based reasoning 
tools can only diagnose what has been modeled. Unanticipated system behavior that has not been modeled will most 
likely lead to a diagnosis that is highly unlikely or misleading. It is important to have simulated data in order to debug 
the model and monitors. Unfortunately, no such data was provided from Boeing (only a few signals from X-40A and X- 
38 were provided). The model and monitors would undoubtedly have to be modified after running through simulated 
data scenarios and after further interaction with Boeing engineers. 

Modeling was made more difficult by the high frequency response of X-37 subsystem components and interaction with 
embedded controllers and fault detection systems. 

Choosing the domain of the model is important for a successful demonstration of Livingstone. Livingstone is a discrete, 
qualitative model-based reasoning engine. Continuous valued systems must be discretized into qualitative bins. Setting 
the number and threshold of the bins must be accomplished by examining system-wide interactions, not just local 
behavior. While this can be done for many cases, the problem becomes more difficult when the expected parameter 
values depend upon the mission phase or upon the duty cycle of the device being modeled. A goal of model-based 
programming is to reduce development time and costs by building a library of components that may be plugged into 
other models^ In order to accomplish this, the model must not have inherent dependencies on the system being modeled 
(function in structure). Currently, defining a model without function in structure is difficult due to the interaction of the 
bin definitions, component failure modes, and system-wide behavior. Also, systems with high frequency feedback loop 
control present challenges to a discrete model. They must be abstracted to a “black-box” level to determine if they are 
functioning properly. "For systems that have on-board health diagnostics, decisions have to be made about 
complementing and enhancing the current fault detection with Livingstone or demonstrating that Livingstone can replace 
the on-board system. The first approach was taken for X-37.. Jn the model, the general rule of thumb was that when 
independent measurements could confirm or refute the status provided by a device, then the status (device) had a failure 
mode; otherwise, the status provided by the system was treated as infallible. 

Successful integration requires experienced modelers and close cooperation with vehicle hardware and software 
developers, or extensive training of vehicle developers. 

We implemented a simple policy engine, which uses a single global timeout value for commands, and another global 
timeout value for unexpected observations. We tuned these parameters to get the system to work correctly for all of our 
scenarios. It is not clear that the values we chose would work correctly with real flight data. Before the system could be 
flown, it would have to be tested with real flight data. The timeout values might have to be further tuned. It is also 
possible that we would discover that the simple approach we took to timing would not be sufficient, and that we would 
have to implement a more sophisticated approach, such as having a different timeout for each command and for each 
observation. 

Our simple policy engine cannot handle interleaved commands - that is, the case where a second command is issued 
before the results of the first command can be observed. One way to extend it to handle certain interleaved commands 



would be to have it ignore (for a time period) only the specific observations that should be affected by a particular 
command. j r ““ 

In the current system, there is no redundancy in our telemetry. Depending on the reliability of the telemetry (which 
depends in part on the adequacy of Boeing’s error detection and correction), we might have needed to implement a 
system dial had redundancy m the telemetry. For example, we could periodically downlink L2’s full state, in addition to 
downhnJang every incremental update to L2’s state. 

We recommend the development of a more formal approach to developing the monitors and the policy engine. 
Currently, these parts of the system are developed by writing C code from scratch for each new vehicle that is modeled. 

Livingstone must be tuned differently for each application. Tunable components include the policy engine (interface 
timing), L- operational parameters (history length, number of candidates, accuracy vs. speed/size, etc)," and monitors 
(data smoothing, persistence, etc). Tuning requires experience, and perhaps art, on the part of integrators. We 
recommend the development of a more formal approach to “tuning” the various parameters of the system. 

One difficulty we encountered is that the X-37 vehicle behaves very differently during different mission phases (such as 
on-orbit reentry, and landing), but L2 uses the same model for every phase. It would be useful if L2 could support 
models that are aware of the mission phase and that model the differences among mission phases. 

Our experience with X-37 has demonstrated the need for a system that can perform hybrid discrete/continuous diagnosis. 
Some parts of the X-37 systems that we modeled are inherently discrete, such as the switches in the EPS. Some parts are 
inherently continuous, such as the voltage in the batteries and the position of the EMAs. In some cases, such as battery 
voltage, it makes sense to use monitors to discretize the continuous values. But in other cases, such as EMA position, it 
is not practical to discretize the values. We found that the only way we could diagnose the functioning of the EMAs in 
“i;, baSed SyStem would be t0 effectiv ely perform the diagnosis within the monitors. We instead chose to rely on the 
X* '? s sensors to tell us whether or not the EMAs were working. We believe that the portion of the X-37 that we 
selected to model in this experiment could be better modeled in a hybrid diagnosis system. 
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